單一 agent 的裝備昨天集齊了，今天講編隊。先把動機說準：multi-agent 不是為了酷，它解的是一個具體的資源限制 — 單一模型的 context window 和注意力有限，任務需要同時探索多個方向、或者中間過程會產生大量雜訊時，一個窗口裝不下。

分工的核心紅利：獨立的窗口

Day 9（RAG）的 LangChain 案例有一段當時沒展開的後續，正好是今天的最佳例子。他們的深度問答 agent 最初的設計是：主 agent 直接收所有搜尋結果：五個完整文件頁面、十二篇知識庫文章、二十個程式碼片段。結果窗口爆炸，答案要嘛冗長要嘛漏重點，Day 8（窗口經濟學）的「分心」教科書案例。

重構後的架構是三個 subagent 分頭處理：文件 subagent 搜五頁、過濾出兩段關鍵段落；知識庫 subagent 掃二十個標題、精讀三篇、回傳摘要；程式碼 subagent 搜五十個檔案、回傳帶行號的關鍵實作。主 agent 只收到每個領域過濾後的精華。

這就是 multi-agent 的核心紅利：每個 subagent 有自己的獨立窗口，中間過程的雜訊死在它自己的窗口裡，只有精煉的結果回到主 agent。搜尋的髒活產生幾萬 token 的中間結果，主 agent 一個字都不用看。

兩種主流架構形狀

Leader-Worker。 Claude Code 的模式：主 agent 當協調者，把具體工作委派給短命的 worker，worker 做完回報就消失。worker 可以在同一個進程裡跑，也可以開成獨立的背景任務。

Agent-as-a-Tool。 deepagents（LangChain 生態的 agent 框架）的模式：subagent 被包裝成一個工具，主 agent「呼叫」它就像呼叫搜尋工具一樣。每個 subagent 宣告自己的名字、描述、專屬工具集，其中描述寫得好不好直接決定主 agent 會不會在對的時機委派，這跟 Day 17（Tool Design）講的工具描述是同一課，subagent 本質上就是一種工具。

兩種形狀的共同原則：委派出去的是任務，回收回來的是結論。中間過程留在 subagent 的窗口裡陪葬。

分工的帳單，和 LangChain 的雙軌答案

分工的代價很具體：每個 subagent 都是一條完整的 LLM 呼叫鏈，錢和時間都成倍數長。還是用同一個 LangChain 案例看數字：他們的單 agent 快速模式，平均三到六次工具呼叫、十五秒內回應；三個 subagent 的深度模式，一跑就是一到三分鐘。品質更好，但你不會想讓每個「怎麼設定 streaming」的簡單問題都等三分鐘。

他們的解法是把兩種模式都留著，預設走快速模式，初始回答解不了問題才升級到深度模式。這就是「什麼時候該分工」在 production 的真實答案：multi-agent 是第二檔，不是預設檔。任務的複雜度配得上編隊的開銷，才切換過去。

並行還有一個工程前提要先鋪好：每個 worker 給隔離的工作空間。兩個 agent 同時改同一份檔案，結果就是互相蓋寫，所以 Claude Code 開 subagent 時可以直接給獨立的 git worktree，NanoClaw 乾脆一個 agent 一個容器（Day 19 的 sandbox 在這裡多了一個用途：隔離不只防破壞，也防隊友互踩）。先隔離，再並行，順序不要反。

誠實版適用邊界

錢和延遲之外還有一筆隱形成本：除錯難度翻倍，一個答案錯了，要追是哪個 agent 在哪一步歪掉。兩個判斷題幫你守住「預設單 agent」這條線：

任務可以拆成互相獨立的子問題嗎？ 拆不開（每一步依賴上一步的完整脈絡），multi-agent 只會把一條推理鏈切碎，單 agent 加上好的 compaction 更強。

中間過程的雜訊量大嗎？ 大（大量搜尋、大量試錯），分工的窗口隔離紅利才吃得到；小，就省下這筆編隊開銷。

編隊完成，往外看

到今天，harness 的內政講完了：單兵裝備加上編隊協作。剩下最後兩題都是「對外」的：agent 要伸手碰外部世界的工具和服務，介面怎麼選？市面上吵翻天的 MCP 是銀彈還是稅？明天用一個 54,600 token 的真實帳單開場，講 MCP、CLI、直呼 API 的選擇邏輯。